feat/waitlist transition - #277

General flow of things (copied from discord):

1. send api post request to /events/{event-id}/begin-waitlist-transition
2. the api queues a task for the waitlist transition to be scheduled on the bat queue
3. the bat worker handles this task, creates a scheduler, and schedules the TransitionWaitlist task set for 72hrs
4. bat worker handles the task timely, calling an application service function which performs moving all accepted&non-confirmed users to waitlist, and accepting 50 oldest waitlisted, queues emails, and the email worker sends them all
5. once acceptanceQuota - totalAccepted < 50 ("acceptanceCount") the scheduler is shutdown

Beyond this another route /events/{event-id}/shutdown-waitlist-scheduler has been made. It also queues a task for the scheduler to be shutdown from the BAT Worker, as the api has no access to the scheduler.

Testing

Everything has been tested locally and on dev infrastructure. Application status and user role numbers appear to change as they should.

Config changes

This has been documented in apps/api/env.dev.example. however for clarity i will include the new parameters in this pr with defaults:

...
ALLOWED_ORIGINS="localhost" # URLs in comma seperated list
EMAIL_TEMPLATE_DIRECTORY="../../internal/email/templates/"

# (((NEW))) Application waitlist
MAX_ACCEPTED_APPLICATIONS=500
ACCEPT_FROM_WAITLIST_COUNT=50
ACCEPT_FROM_WAITLIST_PERIOD="@every 72hr"
# ACCEPT_FROM_WAITLIST_PERIOD="@every 15s" # use this for testing
...

Known issues

• The scheduler is touched in a application service function and a bat service function. But the BAT Worker will be the only one who uses these functions. In the case that the api touches these (as it has access to both services), unexpected behavior or a panic may happen.

(description mostly stolen from #267)